home *** CD-ROM | disk | FTP | other *** search
- Network Working Group D. Walden (BBN-NET)
- Request for Comments: 660 Oct 1974
- NIC #31202
-
-
- SOME CHANGES TO THE IMP AND THE IMP/HOST INTERFACE
-
- In the next few weeks several changes will be made to the IMP
- software including changes to the IMP/Host software interface
- as specified in BBN Report No. 1822, Specifications for the
- Interconnection of a Host and an IMP. These changes come in
- four areas: a) decoupling of the message number sequences of
- Hosts; b) Host/Host access control; c) expansion of the
- message number window from four to eight; and d) provision for
- messages outside the normal message number mechanism. All changes
- are backward compatible with possible minor exceptions in timing.
-
- a. Decoupling of the Host/Host message number sequences:
- Since 1972 the IMP system has provided for exactly four
- messages to be outstanding at a time between any pair of
- IMPs, and thus, a total of only four messages between
- all the possible pairs of Hosts on the two IMPs. Because
- all the pairs of Hosts on the two IMPs have had to share
- the four outstanding messages, it has been quite possible
- for the various Hosts to interfere with each other. To
- remove this possibility of interference, the IMP's
- message number logic will soon be changed to allow a
- separate message number sequence between each pair of Hosts.
-
- To keep manageable the space required to maintain the
- Host/Host message sequences above that presently are required
- for the IMP/IMP message sequences, the Host/Host sequences
- will be taken dynamically from a limited pool of possible
- sequences. The pool will be sufficiently large to seldom
- interfere with a pair of Hosts wishing to communicate. In
- no case will Hosts be prevented from communicating. In
- the event that the Hosts on an IMP desire to simultaneously
- communicate with so many other Hosts that the pool would
- be exhausted, the space in the pool is quickly multiplexed
- in time among all the desired Host/Host conversations
- so that none is stopped although all are possibly slowed.
-
- b. Host/Host access control:
- Upon instructions from ARPA, we will soon add a Host/Host
- access control mechanism to the IMPs. Any pair of Hosts
- wishing to communicate is checked (via bits in the IMP)
- to verify that they have administrative permission to
- communicate. This check normally is made whenever a pair
- of Hosts attempts to communicate after not having
- communicated for two minutes. If the pair of Hosts is
- not allowed to communicate, a special type of Destination
- Dead Message (sub-code 3) is returned to the source
- Host. The default case initially will be to allow all
- Hosts to communicate with each other.
-
-
-
- -1-
-
-
- c. Message number window.:
- Once the message number sequences are on a Host/Host
- rather than IMP/IMP basis, the number of messages that
- will be permitted to be outstanding at a time between
- a pair of Hosts will be expanded from four to eight,
- permitting increased Host/Host throughput in some cases.
-
- d. Message outside the normal mechanism:.
- For certain limited experiments which are being carried on
- using the network, it is thought to be desirable
- for specified Hosts to be able to communicate outside the
- normal ordered, error controlled message sequences.
- Thus, the following expansion to the IMP/Host protocol is being
- provided.
-
- i. a single packet message coming from the source Host
- to the source IMP with a (new) special message type,
- 3, will be put directly into the IMP store-and-forward
- logic with a mark saying the packet is this special
- kind of message. A multi-packet message of type 3
- will be discarded.
-
- ii. such messages (packets) are routed normally to the
- destination IMP, possibly arriving out of order.
-
- iii. at the destination IMP, messages of the special
- type will be put directly on the destination Host
- output queue skipping the reassembly logic and marked
- with a special (new) IMP to Host message type, also 3.
-
- iv. there is no source-to-destination retransmission
- logic, no reassembly, no RFNMs, no incomplete
- transmissions, etc.
-
- v. if at any time there are insufficient resources in the
- network to handle one of these special messages
- (e.g., the destination Host won't take it), the
- message will be discarded.
-
- vi. by using the special message type between the Host
- and the IMP, the normal message number mechanism is
- preserved for all the Host/Host transmissions which
- presently depend on it.
-
- Because the uncontrolled use of this mechanism will degrade the
- performance of the network for all users, the set of Hosts permitted
- to use this mechanism will be regulated by the Network Control
- Center.
-
- Please file this note with your copy of BBN Report 1822 until
- that document is updated.
-
-
-
- -2-
-